home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 7276 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.9 KB
  1. Path: mail2news.demon.co.uk!genesis.demon.co.uk
  2. From: Lawrence Kirby <fred@genesis.demon.co.uk>
  3. Newsgroups: comp.arch.arithmetic,comp.lang.c,comp.lang.c++
  4. Subject: Re: Access carry flag from C
  5. Date: Thu, 22 Feb 96 13:56:18 GMT
  6. Organization: none
  7. Message-ID: <824997378snz@genesis.demon.co.uk>
  8. References: <Dn1C9z.DGv.0.net@indra.com> <1996Feb1922.17.19.879@koobera.math.uic.edu> <31298D20.41C6@bazis.nl> <danpop.824859220@rscernix> <312AFACE.41C6@bazis.nl>
  9. Reply-To: fred@genesis.demon.co.uk
  10. X-NNTP-Posting-Host: genesis.demon.co.uk
  11. X-Newsreader: Demon Internet Simple News v1.27
  12. X-Mail2News-Path: disperse.demon.co.uk!post.demon.co.uk!genesis.demon.co.uk
  13.  
  14. In article <312AFACE.41C6@bazis.nl> fkorntne@bazis.nl "Franz Korntner" writes:
  15.  
  16. >Dan Pop wrote:
  17.  
  18. >> If k is negative, MAXINT-k will overflow :-)
  19. >
  20. >Later I pointed out that this was only true for unsigned numbers.
  21.  
  22. If we're talking about unsigned numbers, k can't be negative.
  23.  
  24. >Why should I start with the difficult case first?
  25.  
  26. Unsigned numbers are the easy case to test for.
  27.  
  28. >> BTW, MAXINT is spelled INT_MAX in C.
  29. >
  30. >I know that and I named it so deliberatly. Because we are testing overflow
  31. >of arithmetic operations we must be aware of the size of the variables. In
  32. >my example I didn't mention the type 'int', I just stated that I assumed
  33. >32 bit numbers.
  34.  
  35. There is no guarantee that a particular implementations supports a 32 bit
  36. type. Whatever type you use you have to use the relevant limits for that
  37. type.
  38.  
  39. >According to the (X3J11 / ANSI) standard, the constant
  40. >INT_MAX (and in this case most limits in limits.h) denotes the minimal
  41. >limit. It is possible that the physical limit is much higher (or lower 
  42. >in the case of negative values).
  43.  
  44. No. The value defined for INT_MAX in limits.h is the maximum value an int
  45. can hold *on that particular implementation*. The standard requires that
  46. INT_MAX be at least 32767 on all implementations (but it can be and
  47. often is higher). So on any implementation:
  48.  
  49.   int x = INT_MAX+1;
  50.  
  51. is a guaranteed overflow.
  52.  
  53.  
  54. >As I am only interested in the physical
  55. >limit, the value INT_MAX has no meaning.
  56.  
  57. INT_MAX defined the physical limit for ints on that implementation.
  58.  
  59. >Only the compiler is fully aware
  60. >of these limits (and not a header file!)
  61.  
  62. Not true.
  63.  
  64. >and what I really miss in the 
  65. >standard and/or implementation is a inline function 'maxlimitof(int)',
  66. >analogical to 'sizeof(int)'.
  67.  
  68. That is precisely what INT_MAX gives you.
  69.  
  70. >What will the future hold for 64 bit or larger machines. For the Alpha
  71. >they declared int to be a 32 bit datatype because too many coders relied
  72. >on this. Real pity as int should denote the natural size of the machine,
  73. >and in the case of the Alpha it should have been 64! But this is a
  74. >totally different discussion.
  75.  
  76. Are 32 bit operations slower than 64 bit operations on the Alpha?
  77.  
  78. -- 
  79. -----------------------------------------
  80. Lawrence Kirby | fred@genesis.demon.co.uk
  81. Wilts, England | 70734.126@compuserve.com
  82. -----------------------------------------
  83.